By Express Mail # EV052Z6336S^' 



FORM PTO-1 390 U.S. DEPARTMENT OF COMMERCE PATENT AND TRADEMARK OFFICE 
(REV 10-94) 

TRANSMITTAL LETTER TO THE UNITED STATES 
DESIGNATED/ELECTED OFFICE (DO/EO/US) CONCERNING A FILING 
UNDER 35 U.S.C. 371 


DOCKET #: 4925-177PUS 










INTERNATIONAL APPLICATION NO. 

PCT/EP99/03517 


INTERNATIONAL FILING DATE 

21 May 1999 





TITLE OF INVENTION 

Packet Data Transmission in Third Generation Mobile System 



APPLICANT(S) FOR DO/EO/US 

Mikko PUUSKARI; Tuija HURTTA; Juha KALLIOKULJU; Tero MAKELA 



Applicant herewith submits to the United States Designated/Elected Office (DO/EO/US) the following items and other 
mformation: 

il-'=l . [x]This IS a FIRST submission of items concerning a filing under 35 U.S.C. 371 . 

2 [J This IS a SECOND or SUBSEQUENT submission of items concerning a filing under 35 U.S.C. 371 

3 [\]This express request to begin national exammation procedures (35 U.S.C. 371(f)) at any time rather than delay 

examination until the expiration of the applicable time limit set in 35 U.S.C. 371(b) and PCT Articles 22 and 
I 39(1). 

j 4 [x] A proper Demand for International Preliminary Examination was made by the 1 9th month from the earliest 

claimed priority date. 
Ls. [x]A copy of the International Application as filed (35 U.S.C. 371(c)(2)) 

a. [x] ^s transmitted herewith (required only if not transmitted by the International Bureau), 
b [x] has been transmitted by the International Bureau. 

-;i c. [] is not required, as the application was filed in the United States Receiving Office (RO/US) 
=6. [] A translation of the International Application into Enghsh (35 U.S.C. 371(c)(2)). 

^rx] Amendments to the International Application under PCT Article 1 9 (35 U.S.C. 371 (c)(3)) 
— .? [x] are transmitted herewith (required only if not transmitted by the International Bureau). ( See Reply to Written 
r=;i 1 Opinion) 

b. [] have been transmitted by the International Bureau. 

c. [] have not been made; however, the time limit for making such amendments has NOT expired. 

d. [] have not been made and will not be made. 

8. [] A translation of the amendments to the claims under PCT Article 19 (35 U.S.C. 371(c)(3)). 

9. [x]An oath or declaration of the inventor(s) (35 U.S.C. 371(c)(4)). Unexecuted 

10. [] A translation of the annexes to the International Preliminary Examination Report under PCT Article 36 (35 

U.S.C. 371(c)(5)). 

Items 11. to 16. Below concern otlier document(s) or information included: 

1 1 .[x] An Information Disclosure Statement under 37 CFR 1 .97 and 1 .98. 

12. [] An assignment document for recording. A separate cover sheet in compliance with 37 CFR 3.28 and 3.3 1 is 

included. 

1 3 . [x] A FIRST preliminary amendment. 

[] A SECOND or SUBSEQUENT preliminary amendment. 

14. [] A substitute specification. 

15. [] A change of power of attorney and/or address letter. 

16. [x]0ther items or information (specify): PCT Publication Sheet, Int'l Preliminary Examination Report, Written 

Opinion, Reply to Written Opinion, Information Concerning Elected Offices Notified of Their Election, Notice 
Informing the Applicant of the Communication of the International Application to the Designated Offices, 
Notification of the Recording of a Change, Notification of Receipt of Record Copy, and PCT Request 



Form PTO-1390 (REV 10-94) 



page 1 of 2 



. ,£y. Express Mail # Ey052763269US 



U.S. APPLICATIOM NO. (If known, see 37 C.F.R. J.5) j INTERNATIONAL APPLICATION NO. 

AQ/gBO^^*- 1 PCT/EP99/03517 


ATTORNEY'S DOCKET NUMBER 

4925-1 77PUS 


17.[x]The following fees are submitted; 


1 


Basic National Fee (37 CFR 1.492(a)(l)-(5)): 

Search Report has been prepared by the EPO or JPO $890.00 

International prdiminary examination fee paid to USPTO (37 CFR 1 .482) $710.00 

No international preliminary examination fee paid to USPTO (37 CFR 1.482) 

but mtemational search fee paid to USPTO (37 CFR 1.445(a)(2)) $740.00 

Neither international preliminary examination fee (37 CFR 1.482) 

nor international search fee (37 CFR 1 .445(a)(2)) paid to USPTO $1040.00 

Intemational preliminary examination fee paid to USPTO (37 CFR 1.482) 

and all claims satisfied provisions of PCT Article 33(2)-(4) $100.00 




ENTER APPROPRIATE BASIC FEE AMOUNT = 


$ 


890 


Surcharge of $130.00 for furnishing the oath or declaration later than [] 20 [] 30 months 
from the earliest claimed priority date (37 CFR 1 .492(e)). 


$ 




Claims 


Number Filed 


Number Extra 


Rate 




Total Claims 


43 - 20 = 


23 


X $18.00 


$ 


414 


Independent Claims 3 - 3 = 


0 


X $84.00 


$ 




":; Multiple dependent claim(s) (if applicable) 


+ $280.00 


S 




TOTAL OF ABOVE CALCULATIONS = 


$ 


1304 


iTReduction of Yz for filing by small entity, if applicable. 


$ 




r SUBTOTAL = 


$ 


1304 


■ Trocessmg fee of $130.00 for furnishing the English translation later than [] 20 [] 30 
• jnonths from the earliest claimed priority date (37 CFR 1 .492(f)). + 


$ 




TOTAL NATIONAL FEE = 


$ 


1304 


See for recording the enclosed assignment (37 CFR 1 .2 1(h)). The assignment must be 
:=aceompanied by the appropriate cover sheet (37 CFR 3.28, 3.31). $40.00 per property 


$ 




TOTAL FEES ENCLOSED 


$1304 




Amount to be refunded: 


$ 




charged: 


$ 



a. [x] One check in the amount of $ 1304 to cover the above fees is enclosed. 

I b. [] Please charge my Deposit Account No. 03-2412 in the amount of $ to cover the above fees. A duplicate copy of 

1 this sheet is enclosed. 

c. [x]The Commissioner is hereby authorized to charge any additional fees which may be required, or credit any 
overpayment to Deposit Account No. 03-2412 . A duplicate copy of this sheet is enclosed. 

j NOTE: Where an appropriate time limit under 37 CFR 1.494 or 1.495 has not been met, a petition to revive 
I (37 CFR 1.137(a) or (b)) must be filed and granted to restore the application to pending status. 



SEND ALL CORRESPONDENCE TO: 
Michael C. Stuart 

Cohen, Pontani, Liebennaii & Pavane 
551 Fifth Avenue, Suite 1210 
New York, New York 10176 



Mfehael C. Stuart 



Registration Number: 35.698 November 15. 2001 



Tel: (212) 687-2770 



Form PTO-1390 (REV 10-94) 



09/980541 

JDIORec'dPCT/PTO , 5 NOV 2001 

By Express Mail # EV052763269US • November 15, 2001 

Attorney Docket # 4925-177PUS 
IN THE UNITED STATES PATENT AND TRADEMARK OFFICE 

In re National Phase PCT Application of 

Mikko PUUSKARI et al. 

International Appln. No . : PCT/EP99/035 17 

International Filing Date: May 21, 1999 

For: Packet Data Transmission in Third Generation 
Mobile System 



PRELIMINARY AMENDMENT 

Assistant Commissioner for Patents 
Washington, D.C. 20231 
BOX PCT 

SIR: 

Prior to examination of the above-identified application please amend the 
application as follows: 

In the Claims : 

Please amend claims 11, 12, 27, and 28 to read as follows: 

11. A method according to claim 7, further comprising the steps of: 

deciding (S35) whether a determined traffic class is a predetermined traffic 

class, and if so 
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discarding (S3 6) those of received data packets which are received after 
subsequently sent data packets. 



12. A method according to claun 7, further comprising the steps of: 

deciding (S35) whether a determined traffic class is a predetermined traffic 

class, and if not so 

monitoring (S37) a sequential relationship among received data packets, 
detecting (S3 8) whether a data packet is missing in the monitored sequence, 

and 

in response to the detection of a missing data packet, buffering (S3 11) 

received data packets. 

27. A network element according to claim 20, wherein said network element is 
a radio network controller (RNC) controlling the transmission of data packets in a packet data 
network in downlink direction. 

28. A network element according to claim 20, wherein said network element is 
a GGSN (Gateway GPRS Support Node) controlling die transmission of data packets in a packet 
data network in uplmk direction. 

Add the following new claims: 
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29. A method according to claim 8, further comprising the steps of: 

deciding (S35) whether a determined traffic class is a predetermined traffic 

class, and if so 

discarding (S36) those of received data packets which are received after 
subsequently sent data packets. 



30. A method according to claim 8, further comprising the steps of: 

deciding (S35) whether a determined traffic class is a predetermined traffic 

class, and if not so 

monitoring (S37) a sequential relationship among received data packets, 
detecting (S3 8) whether a data packet is missing in the monitored sequence, 

and 

in response to the detection of a missing data packet, buffering (S3 11) 

received data packets. 



31. A method according to claim 30, further comprising a step of 

setting (S3 10) a buffering time window, during which time window 
received data packets are buffered. 
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32. A network element according to claim 21 , wherein said network element is 
a radio network controller (RNC) controlling the transmission of data packets in a packet data 
network in downlink direction. 

33. A network element according to claim 22, wherein said network element is 
a radio network controller (RNC) controlling the transmission of data packets in a packet data 
network in downlink direction. 

34. A network element according to claim 23, wherein said network element is 
a radio network controller (RNC) controlling the transmission of data packets in a packet data 
network in downlink direction. 

35. A network element according to claim 24, wherem said network element is 
a radio network controller (RNC) controlling the transmission of data packets in a packet data 
network in downlink direction. 

36. A network element according to claun 25, wherein said network element is 
a radio network controller (RNC) controlling the transmission of data packets in a packet data 
network in downlink direction. 
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37. A network element according to claim 26, wherein said network element is 
a radio network controller (RNC) controlling the transmission of data packets in a packet data 
network in downlink direction. 

38. A network element according to claim 21, wherein said network element is 
a GGSN (Gateway GPRS Support Node) controlling the transmission of data packets in a packet 
data network in uplink direction. 

39. A network element according to claim 22, wherein said network element is 
a GGSN (Gateway GPRS Support Node) controlling the transmission of data packets in a packet 
data network in uplink direction. 

40. A network element according to claim 23, wherein said network element is 
a GGSN (Gateway GPRS Support Node) controlling the transmission of data packets in a packet 
data network in uplink direction. 

41. A network element according to claim 24, wherein said network element is 
a GGSN (Gateway GPRS Support Node) controlling the transmission of data packets in a packet 
data network in uplink direction. 
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42. A network element according to claim 25, wherein said network element is 
a GGSN (Gateway GPRS Support Node) controlling the transmission of data packets in a packet 
data network in uplink direction. 

43. A network element according to claim 26, wherein said network element is 
a GGSN (Gateway GPRS Support Node) controlling the transmission of data packets in a packet 
data network in uplink direction. 
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REMARKS 

This preliminary amendment is presented to eliminate multiple dependency from 
the present claims. No new matter has been added. Early examination and favorable 
consideration of the above-identified application is earnestly solicited. 

Any additional fees or charges required at this time in connection with the 
application may be charged to our Patent and Trademark Office Deposit Account No. 03-2412. 



RespectftiUy submitted, 

COHEN, PONTANI, LIEBERMAN & PA VANE 



By: 



Michael C. Stuart 

Reg. No. 35,698 

551 Fifth Avenue, Suite 1210 

New York, N.Y. 10176 

(212) 687-2770 



15 November 2001 
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AMENDMENTS TO THE SPECIFICATION AND CLAIMS SHOWING CHANGES 

In the Claims: 

11. A method according to claim 7 [or 8], further comprising the steps of: 
deciding (S35) whether a determined traffic class is a predetermined traffic 

class, and if so 

discarding (S36) those of received data packets which are received after 
subsequently sent data packets. 

12. A method according to claim 7 [or 8], further comprising the steps of: 
deciding (S35) whether a determined traffic class is a predetermined traffic 

class, and if not so 

monitoring (S37) a sequential relationship among received data packets, 
detecting (S38) whether a data packet is missing in the monitored sequence, 

and 

in response to the detection of a missing data packet, buffering (S3 11) 

received data packets. 

27. A network element according to [any of the preceding claims] claim 20 [to 
26], wherein said network element is a radio network controller (RNC) controlling the 
transmission of data packets in a packet data network in downlink direction. 
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AMENDMENTS TO THE SPECIFICATION AND CLAIMS SHOWING CHANGES 

In the Claims: 

11. A method according to claim 7 [or 8], further comprising the steps of: 
deciding (S35) whether a determined traffic class is a predetermined traffic 

class, and if so 

discarding (S36) those of received data packets which are received after 
subsequently sent data packets. 

12. A method according to claim 7 [or 8], further comprising the steps of: 
deciding (S35) whether a determined traffic class is a predetermined traffic 

class, and if not so 

monitoring (S37) a sequential relationship among received data packets, 
detecting (S38) whether a data packet is missing in the monitored sequence, 

and 

in response to the detection of a missing data packet, buffering (S3 11) 

received data packets. 

27. A network element according to [any of the preceding claims] claim 20 [to 
26], wherein said network element is a radio network controller (RNC) controlling the 
transmission of data packets in a packet data network in downlink direction. 
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28. A network element according to [any of the preceding claims] claim 20 [to 
26], wherein said network element is a GGSN (Gateway GPRS Support Node) controlling the 
transmission of data packets in a packet data network in uplink direction. 
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TITLE OF THE INVENTION 

PACKET DATA TRANSMISMQN IN THIRD 
"^ISENMAflONliiOBI^^ 



5 

FIELD OF THE INVENTION 



The present invention relates to a method for setting a 
delivery order attribute as a parameter for transmission of 
10 data packets in a packet data network, to a method for 

transmission of data packets in a packet data network, and 
to a network element for controlling transmission of data 
packets in a packet data network which network element is 
adapted to operate according to the latter. 

15 

Particularly, the present invention concerns such methods 
and network elements in connection with the UMTS being 
currently developed (UMTS = Universal Mobile 
Telecommunication System), and more specifically, to PDP 
20 context QoS parameters and their derivation from available 
information as well as there use. (PDP = Packet Data 
Protocol, QoS = Quality of Service). 

BACKGROUND OF THE INVENTION 

25 

Recently telecommunication has made considerable progress, 
A part of this progress manifests in the fact that a user 
may access different networks from a single terminal device 
such as a mobile station MS, and transmit / receive 
30 different kinds of data from / with said terminal. 
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For example, a considerable progress represents the 
possibility to access the Internet from one's mobile 
station and to perform data transfer between the Internet 
and one's mobile station. 

Such data transfers rely on packet data transmission, 
according to which data are transmitted in units of 
packets. An example for a packet data network enabling such 
a packet data transmission is the GPRS network GPRS-NW 
roughly illustrated in Fig. 1. (GPRS = General Packet Radio 
Service) for explanatory purposes. Fig. 1 shows a third 
generation GPRS network part (3G-GPRS) in the UMTS and the 
respective corresponding GPRS components. 

Packet data are for example sent from an external network 
such as the Internet (or the PSTN = Public Switched 
Telephone Network) to a terminal device of a user such as a 
mobile station MS (downlink DL transmission), or vice versa 
(uplink UL transmission). The subsequent brief explanation 
of packet data transmission will now refer to the downlink 
DL transmission. 

The connection between the UMTS (GPRS part) network UMTS 
and the external network is established via a so-called 
3G-GGSN (= 3'''' generation Gateway GPRS Support Node). The 
3G-GGSN as a network element transfers the received data 
via a 3G-SGSN (=3'"'' generation Serving GPRS Support Node) 
(this is optionally, since a GGSN may also act as a SGSN in 
future UMTS standards releases, although at present a SGSN 
is mandatory) to a (radio) network controller device RNC 
(in UMTS; corresponding to a base station controller BSC in 
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GPRS) adapted top control a (radio) access network 
consisting of at least one Node B {in UMTS) (which 
corresponds to a base transceiver station BTS in GPRS) (in 
case of a radio access network) . The access network then 
accesses and communicates with the user's terminal MS. 

In downlink DL, the RNC controls the forwarding of data 
packets to the mobile station as the destination, while in 
uplink the GGSN controls the forwarding of data packets to 
the external network as the destination. 

When forwarding such data packets via the packet data 
network such as a GPRS network, the provisioning of a 
sufficient quality of the service i.e. the transmission of 
data packets, is essential. This is referred to as QoS. 

Provisioning of QoS in GPRS phase 1 could not be 
successfully established. In a subsequent GPRS phase 2, and 
therefore also in a UMTS network, data packets can be 
transmitted using different transmission protocol types. 
For example, the following protocol types are supported: 
UDP (User Datagram Protocol), mostly used for real time 
applications; TCP (Transmission Control Protocol), PPP 
(Point to Point Protocol), X.25 protocol, IP (Internet 
Protocol), OSP:IHOSS (Octet Streaming Protocol : Internet 
Hosted Octet Streaming Service ) . 

All of these PDP types underlie respective different 
requirements. Also, different applications (e.g. real-time 
applications and/or non-real time applications) can be run 
on top of the PDP contexts of the above mentioned PDP 
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types. However, different applications will require ^ 
respective different service from the network. ^ - ^ 



For example, the X.2 5 protocol requires the data packets to 
be sent reliable and delivered in-order, i.e. in the same 
sequence as they were initially transmitted/forwarded. PPP 
protocol, on the other hand, requires a less reliable 
transmission, i.e. some data packets can be lost without 
significantly affecting QoS, but the data packets not lost 
have to be delivered in-sequence. Still further, IP 
protocol based transmissions do neither have to preserve 
the order of the sent packets nor to be reliable in the 
sense that no data packets are to be lost. 

For this purpose, a delivery order attribute as a PDP 
context QoS parameter has recently been defined. To be 
included in a set of UMTS bearer QoS parameters. These 
parameters are still subject to a non-concluded 

dardization process. o^siLyt^^ Q>-rofs2_y ot/^^ot/fe /£ c/e/^-^^c^ , 



30 



The delivery order attribute parameter (DOA) defines for 
UMTS if the order of transmitted packets has to be 
maintained or not. In case the order is to be maintained, 
this leads to the necessity of a node or network element of 
the network (GPRS comparable part of UMTS) to rearrange the 
received (disordered) data packets to thereby reconstruct 
the initial sequence of the data packets as they were sent. ■ 

However, this additional parameter is hard to define by an 
end-user who can be expected not to be an expert in 
telecommunication networks. Namely, such a "normal" end- 

AMENDED SHEET 
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user presumably does not know whether such a property (of 
in-order packets) is necessary for an activated service 
and/or how the property affects the operation. 

5 Moreover, in order to support different applications on top 
of the UMTS bearer, four traffic classes have been 
developed. Namely, a conversational, streaming, interactive 
and background traffic class, respectively. 

10 PDP types mentioned above are independent of the traffic 
classes. Stated in other words, each PDP type (protocol 
type) may run over several traffic classes. IN addition, 
the selection of traffic class sets some requirements for 
the handling of the prevailing traffic in terms of 

15 scheduling and/or buffering of transmitted data packets. 
Also, a delivery order is defined in each traffic class, 
but this is currently not in line with the requirements 
imposed to the traffic classes. 

fix^^Qr ptn'or art: is.\ctnQUjyj -Pr^t^ docoo^euii 31-/jt2Z 

20 SUMMARY OF THE INVENTION 

Hence, it is an object of the present invention to optimize 
data packet transmission for different service while 
simplifying a user interface required for configuring 
25 services available to a user. 

According to a first aspect of the present invention, this 
object is achieved by a method for setting a delivery order 
attribute as a parameter for transmission of data packets 
30 in a packet data network, said method comprising the steps 
of: establishing mapping information for delivery order 
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attributes corresponding to different transmission protocol 
types, detecting a transmission protocol type for the 
transmission of data packets, deciding whether said 
detected protocol type is a predetermined type, and 
setting, based on said mapping information and said 
decision result, the delivery order attribute in case the 
predetermined protocol type is decided to be not present. 

According to a second aspect of the present invention, this 
object is achieved by a method for transmission of data 
packets in a packet data network, said method comprising 
the steps of: detecting at least a delivery order attribute 
as a parameter for transmission of data packets; deciding, 
whether said delivery order attribute parameter is set; and 
if so determining a traffic class of the transmitted data 
packets, and processing the transmitted data packets 
dependent on the determined traffic class. 

still further, this object is achieved by a network element 
for controlling transmission of data packets in a packet 
data network, said network element comprising: first 
detecting means adapted to detect at least a delivery order 
attribute as a parameter for transmission of data packets; 
first deciding means adapted to decide whether said 
delivery order attribute parameter is set; first 
determining means responsive to a positive decision result 
and adapted to determine a traffic class of the transmitted 
data packets, and processing means adapted to process the 
transmitted data packets dependent on the determined 
traffic class. 
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Favorable refinements of the present invention are as set 
out in respective dependent claims. 

According to the first aspect of the present invention, the 
delivery order attribute is set according to a PDP type, 
i.e. a transmission protocol type. Thus, the value of the 
delivery order attribute is derived without necessitating 
an interaction of the end-user. The parameter is thus 
hidden from the end-user, which makes the design of the 
user interface UI more simple. 

According to the second aspect of the present invention, 
data packets are transmitted/forwarded based on a combined 
evaluation of the delivery order parameter and the traffic 
class. Namely, this aspect of the invention proposes that 
the way the delivery order is maintained depends on the 
traffic class of a connection. For example, for real-time 
RT connections and RT traffic classes, delayed data packets 

which are received after a packet Pi {i>k) are 
discarded, while for non-real-time NRT connections, packets 
are buffered and reordered. This is done in case the 
delivery order is required to be maintained. Stated in 
other words, NRT packet delivery is both, in-sequence (if 
required) and more reliable. In summary, a reordering 
process for data packets is optimized for different 
services . 



BRIEF DESCRIPTION OF THE DRAWINGS 

The present invention will be described in the following 
with reference to the drawings, in which 
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Fig. 1 illustrates a simplified block diagram of a GPRS 

network and/or corresponding functional units of a UMTS; 

Fig- 2 is a flowchart explaining a first aspect of the 
present invention in greater detail; 

Fig. 3 (Fig. 3A & 3B) is a flowchart explaining a second 
aspect of the present invention in greater detail; and 

Fig. 4 shows a block diagram of a network element according 
to the present invention. 

DETAILED DESCRIPTIOM OF EMBODIMENTS OF THE INVENTION 

According to a first aspect of the present invention, the 
delivery order attribute DOA is derived from a PDP type, 
i.e. transmission protocol type, respectively. For example, 
considering a case of traffic, i.e. transmission of data 
packets relying on UDP protocol, which in most cases is 
used for real time traffic. In connection with real time 
traffic, it is preferred to discard some data packets 
instead of starting buffering of data packets and waiting 
for individual packets that are lost or at least received 
with delay. In such a case, the delivery order attribute 
should not be set, i.e. should for example be set to a 
value of zero indicating that the data packets need not be 
delivered /forwarded in the sequential order in which they 
were initially transmitted (ordering not required). On the 
other hand, PPP and X.25 protocols, for example, are used 
to run applications which require or at least benefit from 
packets being delivered / forwarded (i.e. received at the 
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destination) in their initial order (sequence) in which 
they were transmitted from the sender side. Moreover, TCP, 
which does not require that the delivery order is being 
kept, will benefit from the delivery order being 
maintained. Also in such a case , the PDP type, namely the 
protocol type, can be used to decide whether the delivery 
order attribute is to be set, and if such a protocol type 
is present, the delivery order attribute is set to a value 
indicating that a delivery of data packets is required in 
sequence (the initial sequence of sending) . New radio 
interface such as MAC (Medium Access Control) / RLC (Radio 
Link Control) defined in UMTS require to be configured to 
deliver data packets either to be in order to deliver data 
packets not necessarily in order , i.e. out of order 
delivery is permissible. 

Fig. 2 shows a more detailed flow chart of this proposed 
method for setting a delivery order attribute as a 
parameter for transmission of data packets in a packet data 
network. 

The method starts in a step S20, which is followed by an 
initiation of packet data transmission in step S21, 

Thereafter, in step S22, a PDP type is detected after a 
mapping information has been established, which mapping 
information has been established for delivery order 
attributes corresponding to different transmission protocol 
types. Namely, information regarding the used transmission 
protocol type (and associated delivery order attributes) is 
acquired. 
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in a following step S23 it is then decided, whether the 
detected protocol is a predetermined one. Also, this is 
intended to mean that it is decided whether the detected 
5 protocol is part of a predetermined group of protocols (a 
group of protocols in the simplest case consists of one 
protocol only). That is, there exist different protocols of 
which part require in-sequence delivery and part do not 
require in-sequence delivery. A predetermined type of 
10 protocol referred to herein below refers to a protocol or a 
set of protocols which do not require in-sequence delivery. 

If a predetermined type of protocol is decided to be 
present {YES in step S23), the flow branches to step S25. 

15 Stated in other words, steps S22 and S23 detect a PDP type 
and decide whether it requires in-sequence delivery or not. 
This may be the case in the event that UDP as a protocol 
for real-time transmission has been detected to be present, 
as mentioned before. Then, in step 525, the delivery order 

20 attribute is not set, i.e. assumes a value of zero, for 
example . 

On the other hand, if said predetermined type has not been 
detected (NO in Step S23) (e.g. a type has been detected 
25 which is not used for RT but rather for NRT transmissions), 
the flow branches to step 824. IN step S24, the delivery 
order attribute is set to a value (e.g. DOA=l) indicating 
that delivery of data packets is required in sequence (the 
initial sequence of sending) 



30 
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After step S24 as well as after step S25, the flow is 
combined and proceeds with a step S26. In step S26, the 
packet data are transmitted together with the delivery 
order attribute DOA (being set (DOA=l) or not set (DOA=0)). 

The flow then ends in step S27. 

As a still further alternative (not shown in the Figure), 
if due to the automatic setting of the delivery order 
parameter some advantageous other properties of 
transmission are adversely affected (e.g. transmission 
quality falls below a predetermined quality threshold), the 
final decision as to the setting of the DOA parameter may 
be left to the. user again, or the parameter may be set to a 
fixed value. 

According to a second aspect of the invention, the above 
set/or non-set delivery order attribute is evaluated in the 
course of transmitting data packets. Specifically, the 
transmission is based on the combined evaluation of PDP 
type requirements and traffic classes, so that a proper 
handling of the delivery order parameter in a respective 
traffic class is resulting therefrom. 

In brief, because in real-time traffic classes the data 
packet scheduling and forwarding must be fast, i.e. real- 
time with hardly any buffering, there cannot be buffering 
of data packets even if the packets are received in a wrong 
order while an in-sequence delivery of the data packets is 
required (i.e. the delivery order parameter DOA is set, 
D0A=1, for the PDP context, namely the protocol type). 
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Packets being received out of order are deleted and/or 
discarded. SO, for example, for a packet stream of #1, #2, 
#3, #5, #6, #4, #7, #8 being received, packet #4 will be 
deleted. 

On the other hand, in connection with non-real-time 
traffic, it makes sense to wait for some time for data 
packets not yet arrived in order to be able to reorder the 
flow of packets. As a specific example only, the ordering 
is based on sequence numbers contained in GTP headers (GPRS 
Tunneling Protocol) of the data packets. Nonetheless 
ordering can be based on RLC numbering in the radio 
interface, i.e. on the information contained in an RLC 
header, as a further example. Generally, this can be based 
on the information contained in any header, as long as the 
respective header contains an indication related to the 
sequence of the packets . 

Therefore, according to the second aspect of the present 
invention the delivery/f orwarding, i.e. transmission of 
data packets is proposed to be handled as follows: 

I.) CONVERSATIONAL AND STREAMING TRAFFIC CLASSES 

(more generally: a first type of traffic class or first 

type group of traffic classes) 

If a delivery order attribute is not set, all incoming data 
packets are forwarded immediately (or at least as soon as 
possible) . 
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However, in case the delivery order attribute has been set, 
a network element (e^g. RNC in downlink direction, GGSN in 
uplink direction of transmission) checks the order of, i.e. 
a sequential relationship among data packets before they 
5 are forwarded to a respective destination (mobile station 
terminal in downlink, external network such as Internet in 
uplink). (It should be noted that the check could also be 
conducted by the closest network node after transmission, 
so e.g. by the SGSN.) If a data packet (or more than one) 
10 arrives after the subsequent packet (with reference to the 
initial order of the packets upon sending), and the data 
packets arrive thus in a wrong order, the disordered 
packet (s) is /are discarded to thereby preserve the right 
order of packets, since buffering and waiting for possibly 
15 disordered data packets does not make sense in case with 
this real-time traffic related traffic class. 

II.) INTERACTIVE AND BACKGROUND TRAFFIC CLASS 

(more generally: a second type of traffic class or second 
20 type group of traffic classes) 

If a delivery order attribute is not set, all incoming data 
packets are forwarded immediately (or at least as soon as 
possible). (In this connection, the behavior is similar to 
25 the first class.) 

In case the delivery order attribute parameter has been 
set, the network element (e.g. RNC in downlink direction, 
GGSN in uplink direction of transmission) checks the order 
30 of, i.e. a sequential relationship among data packets 
before they are forwarded to a respective destination 
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(mobile station terminal in downlink, external network such 
as Internet in uplink) . 

If a data packet is missing, the (next) data packets will 
5 be buffered and the missing data packet will be waited for, 
at least for a specified waiting time also referred to 
hereinafter as a buffering time window. This is for example 
controlled by a timing device which controls buffering and 
waiting. When the timer expires, i.e. the buffering time 

10 window has lapsed, the buffered data packets buffered so 
far are sent and a possibly disordered data packet is 
dropped or discarded even if it arrives later. In case the 
missing data packet arrives prior to the lapse of the 
buffering time window, the buffer can be emptied and the 

15 sending/forwarding is continued until a next packet is 

missing. In this case, of course, the buffered data packets 
are reordered and sent in their initial sequence, with the 
reordering being based on the sequence number contained in 
the a header such as the GTP header or RLC header (or any 

20 other suitable header containing such sequence number 
information) of the packets. 

This ensures, that during most time of the transmission, 
the NRT (non real time) packet delivery is effected both, 

25 in sequence (if required) and reliable (in that only few 
data packets are missing and transmission quality is not 
degraded due to a disordered data stream at the 
destination). A delay caused in this case does not cause a 
remarkable deterioration since NRT can cope with delays and 

30 even with variations in delay. 
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In addition to traffic class information mentioned above, 
also bit error rate (BER) and/or packet loss ratio 
parameter values may be referred to in order to influence 
the decision as to whether data packets are to be buffered 
5 or not for a certain PDP context, i.e. transmission 

protocol. Also, a combined consideration of the previous 
attribute values and a Maximum transfer Delay value may be 
used to define an appropriate value for the buffering time 
window (and/or buffer size). 

10 

Fig. 3 now shows a more detailed flow chart of this 
proposed method for transmission of data packets in a 
packet data network according to the invention. 

15 With reference to Fig. 3A, the method starts in a step S30. 
Thereafter, in step S31, PDP context QoS parameters are 
detected. Among such parameters, at least a delivery order 
attribute parameter DOA is detected. 

20 In step S32, it is decided whether said delivery order 
attribute DOA is set or not. If said delivery order 
attribute DOA is not set (NO in step S32}, the flow 
branches to step S33. According to step S33, data packets 
are forwarded immediately (or at least as soon as possible) 

25 in the order of their receipt to the destination. Then, the 
flow ends in a subsequent step S333. 

If however, it is decided in step S32, that the DOA 
parameter is set (YES in step S32 ) , the flow proceeds to 
30 step S34. 
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in step S34, a traffic class of the prevailing traffic is 
determined. The subsequent processing is dependent on the 
determined traffic class. 

Namely, in a following step S35, it is decided whether the 
determined traffic class is a predetermined one (or belongs 
to a predetermined group of traffic classes, e.g. RT or NRT 
traffic classes). More precisely, in step S35 it is decided 
whether the determined traffic belongs to a first type of 
traffic class (or traffic classes). In the chosen example, 
this first type of traffic class (es) is defined to 
represent a real-time traffic class. 

If this is confirmed in step S35 (YES in step S35), namely, 
if said traffic is RT traffic such as conversational / 
streaming traffic, the flow branches and proceeds with step 
S36. In step S36, disordered packets are discarded and only 
the remaining packets are sent /forwarded to the destination 
in their initial order in which they were sent. For 
example, if a stream of data packets of packets #1, #2, and 
#3 is initially sent in this order, and packets are 
received by the network element in the course of 
transmission to the destination such as a mobile station MS 
in the order #1, #3, and #2, the disorder is detected due 
to the comparison of header information for the packets 
(e.g. information included in the GTP header, RLC header or 
any other suitable header), packet #2 is discarded and only 
packets #1 and 3 (thus in their correct order) are 
forwarded further to the destination. The flow then ends in 
a step S333. 
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In contrast, if in step S35 a predetermined first type of 
■traffic is not decided to be present, i.e. in the described 
example, NRT traffic is concluded to be present, the flow 
advances to step S37 (see Fig. 3B). 

According to step S3 7 the sequence of received data packets 
is determined, i.e. a sequential relationship among the 
received packets is monitored. In a subsequent step S3 8, it 
is detected whether a data packet is missing in the 
sequence of received / monitored data packets. 

With reference to the above example, it is checked whether 
packets #1, #2, and #3 ... are received in this order or 
whether for example packet #2 is missing. 

If no such packet is missing (NO in step S38), the flow 
branches to step S39 and the received packets are sent / 
forwarded in the received order (which in this case is also 
the order of initial sending thereof ) . The flow then ends 
in step S333. 

If, however, a packet is missing (e.g. packet #2) (YES in 
step S38), the method proceeds with step S310. 

In step S3 10, a buffer timer is set, thereby setting a 
buffering time window, during which time window received 
data packets are buffered. The received data packets are 
buffered in step S3 11 and it is waited for the receipt of 
the missing data packet (or packets). During the waiting, 
it is checked, whether the timer has expired (the time 
window has lapsed or not. 
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If the timer has expired (YES in step S312), the flow 
proceeds to step S313, where the buffered data packets are 
sent /forwarded from the buffer to the destination. This 
implies that the missing data packets, if still received 
later, are discarded. With reference to the example given 
in connection with the three packets, if packet #2 is not 
received during the buffering time window, only packets #1 
and #3 are forwarded and packet #2 is discarded if received 
later. The flow then ends in step S333, (it should be noted 
that the discarding of "late-received", i.e. disordered 
packets such as packet #2 is not necessary in all cases, so 
that in the given example there might be cases in which 
packet #2 is also sent to the destination.) 

If, however, the timer has not expired (NO in step S312), 
the flow proceeds to step S314, where it is checked whether 
a missing data packet (or plural missing packets) have been 
received . 

If the packet(s) is (are) received (YES in step S3 14), the 
flow proceeds to step S3 15. In step S3 15 the buffered data 
packets are reordered to their initial sequence order 
(based on the sequence number information contained in a 
suitable header such as for example the GTP header, RLC 
header, LLC header, SNDCP header (layer on top of LLC in 
GPRS), etc.) and forwarded in their initial sequence order. 

Referring to the given example, if packets #1 and #3 have 
been buffered and packet #2 is received during the 
buffering time window so that packets #1, #3, and #2 are 
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present, these are reordered and forwarded in their initial 
sending sequence order of packets #1, #2, and #3 to their 
destination. 

5 If, however, the packets are not received (NO in step S314) 
the flow returns to step S311, and buffering and waiting 
for missing packets continues until either the timer 
expires or the missing packet(s) is (are) received. 

10 The preceding detailed description has been given with 
particular reference to the method. However, the present 
invention also relates to a corresponding device and/or 
network element for controlling transmission of data 
packets in a packet data network, said network element 

15 comprising a first detecting means adapted to detect at 
least a delivery order attribute as a parameter for 
transmission of data packets, a first deciding means 
adapted to decide whether said delivery order attribute 
parameter is set, a first determining means responsive to a 

20 positive decision result and adapted to determine a traffic 
class of the transmitted data packets, and a processing 
means adapted to process the transmitted data packets 
dependent on the determined traffic class. 

25 In detail, such a network element NW-ELEMENT is shown in 
Fig. 4 of the enclosed drawings. Transmitted data packets 
are supplied to the network element and input to a first 
detecting means, which is connected to a first deciding 
means, which in turn is connected to a first determination 

30 means and a subsequent processing means. 
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The processing means as such comprises, as shown in the 
lower part of Fig. 4, a second deciding means connected to 
a discarding means and a monitoring means which are 
responsive to respective decision results of said second 
deciding means. 

The monitoring means as such is connected to a second 
detecting means, an output signal of which is supplied to a 
buffer means. The buffer means buffers the data packets 
supplied thereto via an input (not shown) responsive to the 
signal supplied from the second detecting means. The buffer 
means is set from by means of a setting means, while a 
checking means checks the buffer means in regard of packets 
and/or the order of packets buffered therein. 

The data buffered are read out from the buffer means and 
supplied to a forwarding/reordering means which either 
forwards the buffered data or reorders the buffered data 
packets dependent on a control signal supplied to the 
forwarding / reordering means from the checking means. (The 
processing as performed by these latter means is 
substantially the one as described in connection with the 
flowchart Fig. 3B, particularly steps S311 to S315.) 

The location of such a device / network element within the 
network is dependent on the transmission direction of the 
data packets. For example, in connection with downlink DL 
transmission, the device will be implemented as part of the 
RNC as a network element, while in connection with uplink 
traffic, the device will be implemented as part of the GGSN 
as a network element. 
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It is apparent to those skilled in the art that each of the 
methods steps and its functionality as described herein 
before can be transferred to a corresponding hardware means 
5 adapted to perform the same functionality as described in 
connection with the method step, so that a detailed 
description of a correspondingly adapted device is 
considered to be dispensable. 

10 As has been described herein before, the present invention 
proposes a method for transmission of data packets in a 
packet data network, said method comprising the steps of: 
detecting S31 at least a delivery order attribute DOA as a 
parameter for transmission of data packets; deciding S32, 

15 whether said delivery order attribute parameter is set; and 
if so determining S34 a traffic class of the transmitted 
data packets, and processing the transmitted data packets 
dependent on the determined traffic class S35 to S315. 
Also, the present invention is directed to correspondingly 

20 adapted network elements. Furthermore, the invention 

concerns a method for setting a delivery order attribute 
DOA as a parameter for transmission of data packets in a 
packet data network. 

25 It should be understood that the above description and 

accompanying figures are merely intended to illustrate the 
present invention by way of example only. The preferred 
embodiments of the present invention may thus vary within 
the scope of the attached claims . 
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Amended New Claims 

CLAIMS 

1. A method for setting a delivery order attribute (DOA) as 
a parameter for transmission of data packets 'in a packet 
15 data network (GPRS-NW) , 

said method being characterized by comprising the steps of: 

establishing mapping information for delivery order 
attributes corresponding to different transmission protocol 
types; 

20 detecting (S22) a transmission protocol type for the 

transmission of data packets, 

deciding (S23) whether said detected protocol type is 
a predetermined type, and 

setting (S24) , based on said mapping information and 
25 said decision result, the delivery order attribute (DOA) in 
case the predetermined protocol type is decided to be not 
present . 
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2. A method according to claim 1, wherein said set 

30 delivery order attribute (DOA) indicates that the order of 
transmitted data packets is to be maintained. 

3. A method according to claim 1, wherein said delivery 
order attribute (DOA) is not set (S25) in case the 

35 predetermined protocol type is decided to be present. 

4. A method according to claim 3, wherein said 
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delivery order attribute being not set indicates that the 
order of transmitted data packets does not need to be 
maintained. 

5 5. A method according to claim 1, wherein said 

predetermined protocol type is a protocol type used for 
real-time transmission. 

6. A method according to claim 1, wherein said transmission 
10 protocol type is derived from PDP context information or 

PDP type information. 

7. A method for transmission of data packets in a packet 
data network, said method comprising the steps of: 

15 detecting {S31) at least a delivery order attribute 

{DOA) as a parameter for transmission of data packets; 
further characterized by the steps of 

deciding (S32) , whether said delivery order attribute 
parameter is set; and if so 
20 determining (S34) a traffic class of the transmitted 

data packets, and 

processing {S35-S39, S310-S315) the transmitted data 
packets dependent on the determined traffic class. 

25 8. A method according to claim 7, wherein if said 

delivery order attribute is set, this indicates that the 
order of transmitted data packets is to be maintained. 

9. A method according to claim 7, wherein if said 

30 delivery order attribute is not set, this indicates that 

the order of transmitted data packets does not need to be 
maintained. 
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10. A method according to claim 9, wherein data packets to 
be transmitted are forwarded (S33} to their destination 
immediately and irrespective of the traffic class. 

5 11. A method according to claim 7 or 8, further comprising 
the steps of: 

deciding (S35) whether a determined traffic class is a 
predetermined traffic class, and if so 

discarding (S36) those of received data packets which 
10 are received after subsequently sent data packets. 

12. A method according to claim 7 or 8, further comprising 
the steps of: 

deciding (S35) whether a determined traffic class is a 
15 predetermined traffic class, and if not so 

monitoring (S37) a sequential relationship among 
received data packets, 

detecting (S38) whether a data packet is missing in 
the monitored sequence, and 
20 in response to the detection of a missing data packet, 

buffering (S311) received data packets. 

13. A method according to claim 12, further comprising a 
step of 

25 setting {S310) a buffering time' window, during which 

time window received data packets are buffered. 

14. A method according to claim 13, further comprising a 
step of 

30 checking (S314) whether the missing data packet is 

received during the buffering time window. 

15. A method according to claim 14, wherein 
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if said missing data packet is not received during the 
buffering time window (S314, S312), 

said buffered data packets are forwarded (S313) 
irrespective of the missing data packet, which is discarded 
5 even if received after the buffering time window. 

16. A method according to claim 14, wherein 

if said missing data packet is not received during the 
buffering time window (S314, S312), 
0 said buffered data packets are forwarded (S313) 

irrespective of the missing data packet, which is delivered 
out of sequence even if received after the buffering time 
window. 



15 17. A method according to claim 14, wherein 

if said missing data packet is received (S314) during 
the buffering time window, 

said buffered data packets are reordered to their 
initial sequence order and forwarded in their initial 
20 sequence order (S315) . 

18. A method according to claim 17, wherein 

said reordering is based on sequence numbers of the 
packets contained in headers of the packets. 

25 

19. A method according to claim 18, wherein 

said headers are GTP headers, GTP = GPRS Tunneling 
Protocol, RLC headers, RLC = Radio Link Control, LLC 
headers, LLC = Logical Link Control or SNDCP headers of the 
30 packets. 

20. A network element for controlling transmission of data 
packets in a packet data network, said network element 
comprising : 
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first detecting means adapted to detect at least a 
delivery order attribute (DOA) as a parameter for 
transmission of data packets; 
characterized by 

first deciding means adapted to decide whether said 
delivery order attribute parameter is set; 

first ■ determining means responsive to a positive 
decision result and adapted to determine a traffic class of 
the transmitted data packets, and 

processing means adapted to process the transmitted 
data packets dependent on the determined traffic class. 

21. A network element according to claim 20, wherein said 
processing means further comprises: 

second deciding means adapted to decide whether a 
determined traffic class is a predetermined traffic class, 
and 

discarding means responsive to a positive result of 
said second deciding means and adapted to discard those of 
received data packets which are received after subsequently 
sent data packets. 

22. A network element according to claim 20, wherein said 
processing means further comprises: 

second deciding means adapted to decide whether a 
determined traffic class is a predetermined traffic class. 



monitoring means responsive to a negative result of 
said deciding means and adapted to monitor a sequential 
30 relationship among received data packets, 

second detecting means adapted to detect whether a 
data packet is missing in the monitored sequence, and 

buffer means responsive to the detection of a missing 
data packet and adapted to buffer received data packets. 



and 
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23. A network element according to claim 22, wherein said 
processing means further comprises: 

setting means adapted to set a buffering time window, 
5 during which time window received data packets are 
buffered. 

24. A network element according to claim 23, wherein said 
processing means further comprises: 

10 checking means adapted to check whether the missing 

data packet is received during the buffering time window. 

25. A network element according to claim 24, wherein said 
processing means further comprises: 

15 forwarding means adapted to forward, 

if said missing data packet is not received during the 
buffering time window. 



missing data packet, and to discard the missing data packet 
20 even if received after the buffering time window. 

26. A network element according to claim 24, wherein said 
processing means further comprises: 
reordering means adapted to reorder, 
25 if said missing data packet is received during the 

buffering time window, 

said buffered data packets to their initial 
sequence order, and to forward the buffered data packets in 
their initial sequence order. 



27. A network element according to any of the preceding 
claims 20 to 25, wherein said network element is a radio 



said buffered data packets irrespective of the 



30 



network controller (RNC) controlling the transmission of 
data packets in a packet data network in downlink 



35 



direction. 
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28. A network element according to any of the preceding 
claims 20 to 26, wherein said network element is a GGSN 
{Gateway GPRS Support Node) controlling the transmission of 
5 data packets in a packet data network in uplink direction. 
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POWER OF ATTORNEY: As a named inventor, I hereby appoint the following attorney(s) and/or agent(s) to 
prosecute this application and transact all business in the Patent and Trademark Office connected therewith {List 
name and registration number) 

MYRON COHEN, Reg. No-OIOS^ THOMAS C. PONTANI, Reg. No. 29,763; L ANCE J. 
LIEBERMAN, Reg. No..28,432;.MARTIN B. PA VANE, Reg. No. 28,337; MICHAEL C. STUART, 
Reg. No. ai^aa^LAUS P. STOFFEL, Reg. No. 31^668JEDWARD WEISZ, Reg. No. ^7,257; 
VINCENT M. FAZZARI, Reg. No. 26,879; J ULIA S. KIM, Reg. No. 36,567; ALFRED FROEBRICH, 
Reg. No. 38.887; ALFRED H. HEMINGWAY, JR , Reg. No.^,736; KENT H. CHENG, Reg. No. 
33^49^ YUNLING REN, Reg. No. 47,019; ROGER S. THOMPSON, Reg. No. 29,594;.BRICE 
FALLER, Reg. No. 29,532 ; DAVID J. ROSENBLUM; Reg. N o. 37,7 09; TONY CHEN, Reg. No. 
J4,607i^ELI WEISS, Reg. No. 17,76_5^, 
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Cohen. Pontani, Lieberman & Pa vane__ 
551 Fifth Avenue, Suite 1210 
New York, New York 10176 
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